Aspire PP to wrap Y values around X

[greolt]

I have written an Aspire wrapping PP for those shopbots who have their rotary axis parallel with the X

It is based on the wrapping PP that is provided with Aspire that Randall wrote.

It needs to be tested. Any users with this configuration of rotary, that would be willing to test, PM me.

Greg

[waynelocke]

I would. I just posted to the Aspire forum looking for one.

[eaglesplsh]

FYI... To all using the ShopBot 4th Axis/Indexer PP included in the recent Vectric upgrades:

Yesterday, I emailed Vectric + ShopBot about what I felt was an error/omission in the 4th axis post processor. If you are using this PP or a modified version of this PP you may want to look into this... I believe that SB has an improved version of the PP now - not sure if it's available for download publicly or if you need to call/email to get it.

If you look at the initial feed settings in the Vectric post processor, they do a calculation to convert the given feed rate (used for MY) from ips to degrees per second. This calculated value is used to set the initial MB speed.

This calculation is not repeated when additional cuts are made...(which I believe is a problem)
Say you start with a roughing pass that runs at 6 ips and then you create a finishing pass at 3 ips. Their post will set MY to 6 ips and convert the 6 ips to find the roughing speed in degrees to set up the initial MB speed. When the finishing cut begins, it will set the MY rate to 3ips, __BUT__ the MB rate will still be equal to 6ips - because it was never recalculated/updated (the value from the first cut is still in place.)

This is going to be an even bigger problem if someone tries to modify their post to work with an automatic tool changer and doesn't notice the missing speed change when they switch from a 3/8" cutter to a 1/16" cutter. (I was rewriting the PP for an ATC when I found the problem.)

I'm not trying to slam the folks at Vectric by posting this publicly before they have a chance to verify/respond. I'm very happy with all the great improvements they've made and continue to recommend their products to other CNCers on a regular basis. - Just seemed like timely info to post since Greg started this thread.

[greolt]

That is interesting info Russ

I have insufficient knowledge of the shopbot code to either agree or disagree with your assessment. I use gcode.

The PP in question is one that Randall (a Vectric beta tester) wrote for his own use.

The version which I posted about is simply that same PP, modified to wrap Y values around the rotary and output direction to fit with CNC convention.

I will leave any comment about the rotary axis speed adjustments to Randall.

Greg

[eaglesplsh]

I don't know Randall - and again I'm not trying to blast anyone else or their work. This is just a simple mistake... I spent all day yesterday debugging 25 pages of my own code - PP's, spindle start/stops, tool changes, probing routines, working coordinate offsets, etc.

The PP I was referring to was written by someone named Randall. This may or may not be the same person who wrote the PP that you're using. I've copied the revision history from the PP below, so you can compare it to your own file.

| Who When What
| ====== ========== ========================================
| Tony M 22/06/2005 Written
| Brian M 08/07/2005 Modified to output feed units correctly
| Brian M 14/07/2005 Modified to output 6 d.p
| PACO 15/08/05 Added router control for SB3 Alpha and
| router/spindle RPM dislay/prompt
| Tony 27/06/2006 Added NEW_SEGMENT section
| in case new tool has different
| feedrates to first tool
| Randall 08/10/2009 Added indexer support
| Randall 10/26/2009 Added calculation for rotational feed rate
| Mark 30/10/2009 Renamed file & Post_Name
| Mark M 30/11/2009

[dana_swift]

I have looked into the same problem, and came up with my own PP based on the Vectric one.

My indexer is connected the A axis, so DONT USE THIS POST without modification. My indexer is parallel to the X axis.

For my PP to work Z0 MUST be at the CENTER of the indexer, so Z = Radius. This is an assumption used in the math.

This PP is tested, with the additional correction that as the working radius decreases the linear cut velocity around the indexer remains at the setting specified by the selected tool.

The rotational speed is limited to 720 degrees per second. Use another value if you prefer.

I have run this PP successfully on my alpha indexer, and the values appear to be correct.

I provide no warranty or support as ususal, use at your own risk. It is strongly suggested this file be adapted to your particular installation.

Here is what I am using:


Danas Indexer PP

ShopBot_Indexer_inch.pp (4.8 k)

Hope that helps-

D

[eaglesplsh]

Dana wins the prize!

I was looking for a way to do constant velocity machining, like on a CNC lathe. Somehow I didn't think to include the feed rate calculations right in with the move commands. I figured you could only have 1 line of code in those sections.

Thanks for sharing - your genius makes for much better cut files.

Have you talked to SB/Vectric about this yet? I'm sure they would appreciate it.

[greolt]

By convention the rotary axis direction of rotation should follow the right hand rule.

To correct for this use this line,

ROTARY_WRAP_X = "-"

Greg


49967.jpg

PS: Would not normal motor tuning parameters take car of the max speed of the rotary? Is this line needed?

"if &AngularFeedRate > 720 then &AngularFeedRate = 720"

Again, I use gcode, so forgive me if I am barking up the wrong tree.

[dana_swift]

Greg, there is NO standard as to which end of the rotary axis gets the motor. It can be mounted either to the near X0 end or at the far end with the tailstock at X0. Either way is just fine and matter of personal preference, use the - sign in the PP to change it to work in your installation.

As the radius approaches zero the RPM attempts to go to infinity. Protection must be provided for both divide by zero and some upper limit for rotation rate. The time it is needed is when a piece is only supported by the chuck, and cutting past zero would attempt to reverse the rotation direction. My note is that is my decision to limit the rotation rate to 720 degrees/sec. Its just a judgment call, and I noted that each user may prefer some other value (or none). Any given cut file may never approach a radius of zero and the protection may be removed. I don't make that assumption. It does not slow down cutting or the time to complete cutting the file.

It doesn't matter if the motion is encoded in gcode, sbp code, or hieroglyphics the math is the same. I have no idea what you are talking about "motor tuning parameters". Is there a PID controller somewhere I could be toying with?

I commend Vectric for making the post processor documentation available so anybody can do it their way. You have seen what I have done, as I said, it is provided "as is".

D

[greolt]

You are right there is NO standard as to which end is the drive or headstock.

But there IS a standard as to the direction of rotation.

The right hand rule concisely describes this standard direction of rotation, no matter which end is the headstock.

That is why any text book that I have ever seen uses the right hand rule as the description method.

If a CNC user wants to have their direction of rotation different to convention then that is fine. They can do whatever they want.

But there IS a conventional direction for all axis travel.

Greg


49971.jpg